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a called address, i.e. B-number, no longer refers 
to the subscription network/number range owner 
and the old rale "the number range of the called 
party reveals the tariff level" is no longer valid. To 
overcome this defect all intelligent network-like 
service invocation requests are routed (3-2) via 
a network node performing a number portability 
function to the network node controlling the 
service. The node performing the number 
portability function performs (3-3) a mapping 
of the B-number and relays (3-4) the service 
invocation requests indicating the subscription 
network/number range owner. 
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Number portability and services utilizing number range owner 
information 

FIELD OF THE INVENTION 

The present invention relates to implementing number portability, 
5 and more particularly to how to make sure that an intelligent network-like ser- 
vice utilizing a called party address can count on that the called party address 
indicates the right subscription network/number range owner. 

BACKGROUND OF THE INVENTION 

Number portability NP is a service where the subscriber can keep 

10 his old telephone number within a portability cluster and thus retain easy con- 
tactability. In a fixed network, number portability means in that the subscriber 
can change his location and even his operator and still have the same phone 
number. In mobile networks, number portability means that a mobile sub- 
scriber can change his subscription network without changing his telephone 

15 number for terminating traffic. One major feature of NP is that it should have 
no influence on the services offered. In other words, regardless of whether the 
number of a subscriber is ported or not, the services offered to the subscriber 
should be the same. A ported number means a number that has undergone a 
porting process (i.e. transfer) between locations, operators or subscription 

20 networks. 

In wireless networks, number portability is usually implemented with 
a Mobile Number Portability Signalling Relay Function (MNP-SRF) and/or as 
an lN-based solution e.g. with a CorelNAP interface. In fixed networks, num- 
ber portability is usually implemented as an IN-based solution. In mobile num- 

25 ber portability, the MNP-SRF is mandatory for non-call-related signalling. An 
intelligent network IN is a network architecture attached to a basic network 
(fixed or mobile network, for example), which enables faster, easier and more 
flexible implementation and control of services. This is achieved by moving 
service control away from the switching centre to a separate functional unit in 

30 the intelligent network. 

A problem arises when an IN service of the calling subscriber util- 
izes the number range of a B-number, i.e. the called telephone number, for 
determining a service parameter, such as tariff level. Because of number port- 
ability, the B-number no longer refers to the subscription network/number 

35 range owner and the old rule "the number range of the called party reveals the 
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tariff level" is no longer valid. One example of an IN service utilizing the sub- 
scription network/number range owner is a prepaid subscription. The prepaid 
subscription involves no billing in arrears but the account of the prepaid sub- 
scription is charged real-time during calls. In solutions based on an intelligent 
5 network, a prepaid subscription is charged in phases and usually at least two 
network nodes participate in the charging. The balance of the account is moni- 
tored in a network node controlling the service and called a service control 
point (SCP). SCP determines, for example, a reserved credit, which is the 
amount of money reserved from the balance for this call for a certain period of 

10 time. The amount of the reserved credit depends on a threshold, which is a 
network parameter usually expressed as time, and on a price of one time unit 
for this call. The price is usually determined on the basis of the B-number 
range owner/subscription network of the B-number. SCP sends the threshold 
to a service switching point (SSP). The service switching point is a call 

15 monitoring network node, for example a mobile switching centre. When for 
example the time indicated by the threshold has elapsed, SSP reports this to 
SCP and at the same time requests another threshold. However, the threshold 
determination described above can not be used with number portability, since 
the B-number does not necessarily reveal the subscription network/number 

20 range owner, and thus it can not be used for determining the time. 

Another service similar to the prepaid service with a similar problem 
is a postpaid service with a limited bill, i.e. a postpaid subscription with a limit 
indicating the maximum allowed amount to be billed. It differs from the prepaid 
subscription in that the subscription allows access to chargeable connections 

25 or services until the bill reaches the limit. 

BRIEF DESCRIPTION OF THE INVENTION 

An object of the present invention is to provide a method and an 
apparatus for implementing the method so as to overcome the above problem. 
The object of the invention is achieved by a method, a system and network 
nodes which are characterized by what is stated in the independent claims. 
Preferred embodiments of the invention are disclosed in the dependent 
claims. 

The invention is based on the idea of routing all intelligent network- 
like service invocation requests via a network node performing the number 
portability function to the network node controlling the service. The node per- 
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forming the number portability function performs the mapping of the B-number 
and relays the service invocation request with the B-number indicating the ad- 
dress range. In this context the term 'address range' refers to subscription 
network, number range owner, domain and location of a subscriber. An advan- 
5 tage of the invention is that services utilizing information on the subscription 
network/number range owner need not be modified to take into account num- 
ber portability in networks supporting number portability. Thus, there is no 
need to modify the node controlling the service to request the subscription 
network/number range owner from the node performing number portability. A 

10 further advantage is that the signalling load in the network can be reduced 
compared to a request made by the node controlling the service, and the ser- 
vice logic in the node controlling the service need not be amended; they can 
stay as they were before number portability. Another advantage of the inven- 
tion is that it can also be employed with services utilizing non-call-related sig- 

15 nailing, such as a short message service, as they use the same service invo- 
cation mechanism. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following, the invention will be described in greater detail by 
means of preferred embodiments with reference to the attached drawings, in 
20 which 

Figure 1 is a block diagram illustrating some network nodes of a 
telecommunications system of a first preferred embodiment of the invention; 

Figure 2 is a flow chart illustrating the functionality of a service rout- 
ing register in the first preferred embodiment of the invention; and 
25 Figure 3 illustrates signalling according to the first preferred em- 

bodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention can be applied to any communications sys- 
tem supporting number portability. These systems include so-called third gen- 

30 eration mobile communications systems, such as the Universal Mobile Tele- 
communications System (UMTS), and so-called second-generation mobile 
communications systems, such as the pan-European GSM (Global System for 
Mobile Communications) and corresponding mobile communications systems, 
such as DCS 1800 (Digital Cellular System for 1800 MHz) and PCS (Personal 

35 Communication System), as well as systems based on the ones mentioned 
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above, such as GSM 2+ systems, and fixed systems, such as the PSTN (Pub- 
lic Switched Telephone Network). The invention can also be implemented in 
an environment where the actual number portability is implemented with a dif- 
ferent platform than disclosed here, such as another MNP-SRF or CSF. 
5 A service providing an intelligent network-like control refers both to 

services offered by a conventional intelligent network and to services employ- 
ing intelligent network control principles. Intelligent network control principles in 
turn refer to a solution where an event checking function handling a call con- 
tacts a service control function which may provide the event checking function 

10 with instructions affecting the handling of the call. The contact may be a notifi- 
cation or a request. When the contact is a request, the event checking function 
either interrupts call processing and waits for an instruction(s) or continues call 
processing and receives the instruction(s) later. The event checking function 
contacts the service control function on the basis of armed event data in the 

15 event checking function. Armed event data can be added and/or deleted at the 
request of an external service during the call setup process, or even before the 
call setup process is started. The call can be depicted as a state model visible 
to the control function, the state model being formed of phases and detection 
points associated with them. Detection points refer to armed events, i.e. to 

20 those call stages and interaction points, if any, where the service control func- 
tion may influence the call and/or receive information relating to the call. An 
entity to be controlled may also operate for example on external impulses 
alone which generate the triggers and/or other armed events, in which case a 
state model is not necessarily needed. A trigger is an armed event which trig- 

25 gers a service when certain conditions are met, i.e. it activates the service. 
The controls and operations may also be methods directed to call objects and 
event notifications associated with them. Examples of protocols employing 
intelligent network-like call control include Parlay API (Application Protocol In- 
terface), OSA (Open System Architecture) and SIP (Session Initiation Proto- 

30 col), and naturally different intelligent network protocols, such as WIN (Wire- 
less Intelligent Network) and CAMEL (Customised Applications for Mobile 
Network Enhanced Logic) application protocol CAP. 

Here the term 'call 1 refers not only to a conventional call, but also to 
other, possibly virtual, connection states where user data, such as data ses- 

35 sions or packet data, are transferred. Examples of such include packet radio 
sessions (such as GPRS sessions), VoIP sessions (Voice over IP) and multi- 
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media sessions according to H.323. The user data may comprise various 
components, such as voice, video and data. The term 'call' also includes the 
signalling needed to transfer the user data flow and call-like services, which 
may be unidirectional services, those addressed to a group (or groups), or 
5 general broadcasts within a specific area, for example. 

In the following, the invention will be described using the CorelNAP 
terminology of the standard ETSI 300 374-1 without, however, limiting the in- 
vention to that kind of a particular intelligent network protocol. 

Figure 1 shows a simplified network architecture, only describing 

10 elements and functions that are needed to illustrate the invention. The network 
nodes illustrated in Figure 1 are logical units, the implementation of which may 
differ from the described one. It is obvious to one skilled in the art that the sys- 
tem 1 may also comprise other functions and structures which need not be 
described in closer detail here. 

15 Network nodes responsible for intelligent network interfaces are 

called service switching points SSP, and they contain at least a service switch- 
ing function SSF and a call control function CCF, the combination of which is 
one example of the event checking function. The call control function CCF is 
not a function related to the intelligent network, but a standard switching centre 

20 function comprising high-level call processing functions of the centre, such as 
the set-up and release of transmission links. The service switching function 
SSF provides the interface between the call control function CCF and the ser- 
vice control point SCP. A network node comprising the service switching func- 
tion SSF detects for example call set-up events, i.e. triggers that may trigger 

25 an intelligent network service. An intelligent network service is triggered when 
certain pre-determined conditions are met. When triggering the intelligent ser- 
vice, SSF sends a service invocation request. The SSP according to the inven- 
tion is configured to route service invocation requests via SRR (Service Rout- 
ing Register) as described in greater detail with Figure 3. SSP is a network 

30 node which is typically responsible for connection set-up, such as a switching 
centre in a basic network or in a mobile communications system. Thus, SSP 
can be a mobile switching centre MSC or a fixed switching centre FSC , or a 
network node comprising a call state control function CSCF , for example. 
Here the service switching point SSP is equal to the functional entity formed by 

35 CCF and SSF, so the term SSP will be used hereinafter. 
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Network elements that include the service control function SCF are 
called service control points SCP. The service control function is a centralized 
authority in the intelligent network, which comprises an execution environment 
for service logic programs, among other things. Here SCF and SCP are equal 

5 in value, and hereinafter the term SCP will be used. In connection with an IN- 
like service, a service logic program is invoked at the service control point 
SCP, the operation of said program determining the instructions that SCP 
sends to SSP in each call step. The service control point SCP of Figure 1 
shows the service control point at its simplest. The term 'service control point* 

10 covers here different platforms and application servers which control services 
according to intelligent network-like principles. 

The service control function for number portability SCFJvlP com- 
prises the necessary control functions for providing the number portability ser- 
vices. SCF_NP can also be a called service relay function (SRF) or a signal- 

15 ling relay function for service invocation requests (SRF-S). The service control 
point comprising SCF_NP is called SRR (Service Routing Register). The 
number portability service also requires a database NPJDB (Number Portabil- 
ity Database). In the example illustrated in Figure 1, the database NP_DB is 
an internal database, but it may also be an external database and even a de- 

20 centralized database. SRR may comprise only the number portability function- 
ality, or it may also have capabilities for other purposes. 

The system implementing the functionality of the present invention 
and the network nodes of the system comprise not only prior-art means, but 
also means for implementing the functions described in greater detail in con- 

25 nection with Figures 2 and 3. More specifically, they comprise at least means 
for routing service invocation requests via SRR to SCP and means for 
performing number portability mapping at least to the B-number in the service 
invocation request. The present network nodes comprise processors and 
memory that can be utilized in the functions of the invention. All changes 

30 needed for implementing the invention can be accomplished as added or up- 
dated software routines, using application-specific integrated circuits (ASIC) 
and/or programmable circuits, such as EPLD, FPGA. It is assumed that prior- 
art means support number portability, i.e. SSP, SRR, HLR and SCP are 
configured to support number portability and recognize the routing numbers, 

35 for example. 
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Figure 2 illustrates the functionality of SRR in the first preferred em- 
bodiment of the invention where the system is a mobile communications sys- 
tem supporting at least CAP and INAP (Intelligent Network Application Proto- 
col), such as CorelNAP. For the sake of clarity, the term 'message 1 covers 
5 here also the terms 'service request 1 and 'operation 1 which are commonly used 
in the intelligent network instead of the term 'message*. In the example illus- 
trated in Figure 2, it is assumed, for clarity's sake, that the only service logic in 
SRR is the service logic for number portability. In other words, the requests 
relating to number portability are the only ones assumed to be answered by 

10 SRR in the first preferred embodiment of the invention. It is also assumed, for 
clarity's sake, that at least all ported numbers or addresses within a portability 
cluster are included in the Number Portability Database, i.e. direct routing is 
used as a routing convention. When the invention is applied to tariffing and 
direct routing is used, the Number Portability Database should include within 

15 the portability cluster at least all ported numbers or addresses affecting tar- 
iffing. 

In the first preferred embodiment of the invention, two factors are 
determined. SRR uses these factors when deciding whether the received 
message is a message SRR should respond to or a message to be relayed. 

20 The first factor determines the protocol(s) used to relay messages 

SRR should respond to. An example of such a protocol is INAP. Messages 
according to other protocols, not used by a standardized IN-based solution to 
perform a number portability request, such as CAP, are interpreted as mes- 
sages to be relayed. In other words, with the first factor, protocols can be di- 

25 vided into protocols used for number portability enquiries and protocols not 
used for number portability enquiries in the first preferred embodiment. 

The second factor determines within a protocol the used service key 
value(s) for the messages SRR should respond to, the service key value(s) 
indicating the service logic to be performed in SRR. In the first preferred em- 

30 bodiment of the invention, a service key value NP indicates that the service 
logic for number portability should apply and a message having another ser- 
vice key value is a message to be relayed. In other words, the service key 
value is used to decide whether SRR should respond to the message or 
whether the message is a message to be relayed. When SRR supports sev- 

35 eral protocols, the service key values may also be determined to each protocol 
separately. 
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With these two different factors a problem relating to service keys is 
solved. The service invocation request includes a service key or a correspond- 
ing parameter indicating the service logic the invocation relates to. The service 
key is added by SSP. However, the service key value for the number portabil- 
5 ity service is not standardized and the allocation of the value is not coordi- 
nated between different networks (operators). In some protocols, like CAP, the 
service key is administrated by the subscription network, i.e. home operator, in 
order to provide roaming subscribers intelligent services of the home network. 
In some protocols, such as I NAP, the service key is administrated by network 

10 elements in the visited network. Thus a service key value given in a home 
network for a CAP service invocation request indicating a call barring can be 
the same service key value given in a visited network for number portability 
requests. This possible confusion is overcome by the first factor. 

Referring to Figure 2, SRR receives, in step 201, a message and 

15 determines, in step 202, whether the message is a message according to 
INAP, i.e. an INAP message. The determination of the protocol can be based 
on checking the Application Context of the message, for example. The Appli- 
cation Context comprises information on the used protocol. The information is 
unique in different intelligent network-like protocols and thus unambiguously 

20 indicates the protocol used by the message. 

If the message is an INAP message (step 202), SRR checks, in 
step 203, whether the service key value in the message is NP, i.e. whether the 
service key indicates that service logic for number portability should apply. 

•< If the service key is not NP, SRR maps the called party address to 

25 the number portability database. In other words, SRR checks, in step 204, 
whether the called party address B# is in the number portability database 
NP_DB. 

If the called party address B# was in the number portability data- 
base NP_DB, the called party address is a ported address, and SRR adds, in 
30 step 205, into the message received in step 201, an indication indicating the 
subscription network HPLMN, i.e. an indication indicating the subscription net- 
. work/number range owner of B#. The indication is preferably a prefix preced- 
ing the called party address and directly indicating HPLMN. The prefix is pref- 
erably the routing number of subscriber B. The routing number depends on the 
35 configuration of the network and it may be any number. The routing number 
may comprise the country code, for example. Other kinds of indications may 
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also be used, such as parameters or replacing the called party address B# 
with a number indicating the right subscription network/number range owner. 
After the indication is added (step 205), SRR relays, in step 206, the message 
towards its destination address, i.e. towards the network node invoking the 
5 service, i.e. towards SCP comprising the service logic. 

If the called party address B# was not in the number portability da- 
tabase NP_DB (step 204), the called party address is not a ported address 
and it indicates the right subscription network/number range owner. Then there 
is no need to modify the message and SRR thus proceeds to step 206 to relay 
1 0 the message towards its destination address. 

If the service key was NP (step 203), SRR performs, in step 207, 
the number portability process, i.e. current subscription network ported status 
checking. 

If the message was not an INAP message (step 202), it is in the first 
15 preferred embodiment of the invention a CAP message, and SRR proceeds to 
step 204 to check, whether B# is in NPJDB, continuing the process as de- 
scribed above. 

When indirect routing is used as the routing convention, all 
HPLMN's own ported numbers (ported out and ported in) are in NP_DB and 

20 the others are not there. In that case, the called party address indicates the 
right subscription network/number range owner to HPLMN's own subscribers. 
However, the called party address of a visiting subscriber does not necessarily 
indicate the right subscription network/number range, since all ported numbers 
of other subscription networks (PLMNs) belonging to the same portability clus- 

25 ter with HPLMN are not in NPJDB. Therefore, the invention can be applied to 
'off-network' and 'on-network' tariffing when indirect routing is used. 

The steps in Figure 2 are not in an absolute chronological order. For 
example, some of the above steps may take place simultaneously, or in an- 
other order. Some steps may be omitted, such as checking the service key 

30 value in embodiments where one protocol is used between SSP and SRR and 
another between SSP and SCP, i.e. in embodiments where the used protocol 
always indicates whether or not SRR should respond. In embodiments, where 
the same protocols are used between SSP, SRR and SCP, the determination 
of the used protocol may be omitted since it does not reveal whether or not a 

35 message is a message to be skipped over. Correspondingly, other steps not 
shown in Figure 2 may take place between the above-mentioned steps, such 



WO 02/054786 PCT/FI01/01148 



10 

as checking other service key value(s) for other services to be performed in 
SRR. Examples of other service logics in the SRR are caller address (i.e. A- 
number) validation and trigger information. 

Figure 3 illustrates signalling according to the first preferred em- 
5 bodiment of the invention. SSP encounters a trigger, i.e. detects a service in- 
vocation, in point 3-1. In the example of Figure 3, it is assumed that the de- 
tected service invocation (i.e. encountered trigger) relates to a prepaid service, 
and SSP adds a service key SK indicating the prepaid service in point 3-1 into 
the service invocation request. SSP adds the address of SCP into the service 

10 invocation request and all the information needed for the service triggering. 
Then SSP according to the invention sends the service invocation request in 
message 3-2 to SRR. 

SRR receives message 3-2, finds out that message 3-2 is not a 
message relating to number portability NP and performs the B-number map- 

15 ping against the number portability database (as described earlier with Figure 
2), in point 3-3, and modifies, if needed, the B-number to indicate the subscrip- 
tion network/number range owner as described earlier with Figure 2. Then 
SRR relays the service invocation request in message 3-4 to SCP. 

SCP recognizes in the example illustrated in Figure 3 that message 

20 3-4 relates to prepaid services and it notes the right indication about the tariff 
from B-number in message 3-4 since B-number indicates the subscription 
network/number range owner. Thus charging can be created in the system 
with a right tariff level based on the received called party address or prefixed 
called party address. After determining the threshold for the prepaid service, 

25 SCP sends the threshold (or some other instructions) directly to SSP in mes- 
sage 3-5. 

In the first preferred embodiment of the invention the SSP uses the 
addressing of an SCCP (Signalling Connection Control Part) protocol so that 
an indication 'route on GT (Global Title) 1 causes the message to be routed to- 

30 wards SRR. SRR then performs GT translation according to SCCP, the out- 
come of which indicates the address of SCP. Another possibility is that the 
subscriber information or information relating to the service invocation contains 
a direct address to SRR and that address is used to route the request to SRR 
which then performs GT translation. 

35 In one embodiment of the invention, SSP is configured to send only 

service invocation requests with B-number(s) via SRR and other service invo- 
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cation requests directly to SCP. In another embodiment of the invention, SSP 
is configured to send only service invocation requests with predetermined B- 
number(s) via SRR and other service invocation requests directly to SCP. The 
predetermined B-numbers may comprise the numbers of home subscribers or 
„ 5 numbers within the portability cluster, e.g. numbers comprising a certain coun- 
try code, such as +358 for Finland, In yet another embodiment of the inven- 
tion, SSP is configured to send only service invocation requests with B- 
numbers via SRR and other service invocation requests directly to SCP, the 
service invocation requests relating to certain short numbers, such as VPN- 

10 numbers (Virtual Private Numbers) are routed directly to SCP and others via 
SRR. Directly means either transparently via SRR or via direct connection be- 
tween SSP and SCP. 

Although the invention has been described above with a called 
party address, it is obvious to one skilled in the art how to apply the invention 

15 to services based on a caller's number range, i.e. on the number range of the 
calling address A. One example of such a service is barring based on a sub- 
scriber's telephone number's (MSISDN) country code. 

Although the invention has been described above with mobile tele- 
communications system, it is obvious to one skilled in the art how to imple- 

20 ment the invention in a fixed system where the invention can also be applied 
to determine the proper location. 

Although the invention has been described above assuming that at 
least the used protocol or the service key indicating the service logic are used 
to decide whether the message is one to be relayed or one SRR should re-. 

25 spond to, it is obvious to one skilled in the art that they are only examples of 
factors with which one can separate the messages. Also other factors with 
which SRR can recognize whether the message is one to be relayed or one to 
be responded to may be used instead of or in addition to the above-mentioned 
factors. For example, messages comprising the address of SCP may be the 

30 ones to be relayed and messages without the address of SCP the ones to be 
responded to. 

Although the invention has been described above with CAP and 
I NAP, it is obvious to one skilled in the art that the invention can be imple- 
mented c with other protocols, including future protocols not known at the time 
35 the invention was made, which are used to initiate services. 

Although the invention has been described above with Number 
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Portability, it is obvious to one skilled in the art that the invention can be im- 
plemented with corresponding services, such as Logical Name Portability for 
IP Multimedia services, and even mapping of logical names without portability 
service when a streamlined function for mapping of a right tariff level from the 
5 logical name is needed. Here the term 'number portability 1 covers also this kind 
of mapping. The logical name, such as user@domain or an URL (Uniform Re- 
source Locator) address, hides the actual IP-address. 

It will be obvious to one skilled in the art that, as technology ad- 
vances, the inventive concept can be implemented in various ways. The inven- 
10 tion and its embodiments are not limited to the examples described above but 
may vary within the scope of the claims. 
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CLAIMS 

1 . A method of providing a service using information based on an 
address range in a communications system comprising at least a first entity 
invoking the service and a second entity having access to a number portability 
5 database, the method comprising at least the steps of: 

detecting (3-1) a service invocation of a service to be invoked by the 

first entity; 

routing (3-2) a request comprising an address and relating to the 
service invocation to the first entity via the second entity; 
10 characterized by 

mapping (3-3) in the second entity the address to the number port- 
ability database; and 

relaying (3-4) from the second entity to the first entity the request 
which indicates the address range of the address. 
15 2. A method according to claim ^characterized by 

determining in the second entity that the request is to be relayed to 
the first entity on the basis of the protocol used in the request, and 

performing said mapping if the request is to be relayed to the first 

entity. 

20 3. A method according to claim ^characterized by 

adding a service key indicating the service into the request in re- 
sponse to detecting the service invocation; 

determining in the second entity that the request is to be relayed to 
the first entity on the basis of the service key in the request, and 
25 performing said mapping if the request is to be relayed to the first 

entity. 

4. A method of relaying a service invocation request in a communi- 
cations system, the method comprising the steps of: 

receiving (201) the service invocation request in a network node 
30 providing at least a number portability service using a number portability data- 
base; 

characterized by 

determining (202, 203) whether the service invocation request re- 
lates to services provided in the network node; 
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if it does, triggering (207) the service the service invocation request 

relates to; 

if it does not, the method further comprises the steps of: 

- mapping (204, 205) an address in the service invocation request 
5 to the number portability database; and 

- relaying (206) the service invocation request which indicates at 
least the address range of the address. 

5. A method according to claim 4, characterized by recog- 
nizing (203) that the service invocation request relates to services provided in 

10 the network node on the basis of the service key value in the service invoca- 
tion request. 

6. A method according to claim 4 or 5, characterized by 
recognizing (202) that the message does not relate to services provided in the 
network node on the basis of the protocol of the service invocation request. 

15 7. A method according to any one of the preceding claims, char- 

acterized in that 

if the address is in the number portability database, the address 
range is indicated by an indication added into the request before relaying (3-4) 
the request; and 

20 if the address is not in the number portability database, the address 

itself indicates the address range. 

8. A method according to any one of the preceding claims, 
characterized by 

the number portability database comprising information on at least 
25 ported addresses of home subscribers; and 

the address range indicating whether the subscriber is a home sub- 
scriber or a visiting subscriber. 

9. A method according to any one of the preceding claims, 
characterized in that the address range is used to determine a tariff 

30 level to be used. 

10. A method of relaying a service invocation request in a commu- 
nications system, the method comprising the steps of: 

receiving (201) the service invocation request in a network node 
providing at least mapping of logical names with an address indicating a tariff 
35 level; 

characterized by 
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determining (202, 203) whether the service invocation request re- 
lates to services provided in the network node; 

if it does, triggering (207) the service the service invocation request 

relates to; 

5 if it does not, the method further comprises the steps of: 

- performing the mapping to the address in the service invocation 
request; and 

- relaying the service invocation request with an address indicating 
the tariff level. 

10 1 1 . A system (1 ) comprising at least 

a number portability database (NPJDB) comprising ported numbers; 
a first node (SSP) for encountering a trigger for a service and, in re- 
sponse to the encountering, sending a service invocation request; 
a second node (SCP) for invoking the service; and 
15 a third node (SRR) for providing at least a number portability service 

(SCFJMP);. 

wherein the first node (SSP) is configured to send the service invo- 
cation request to the second node (SCP) via the third node (SRR); 
characterized in that 
20 the third node (SRR) is arranged to determine whether the service 

invocation request relates to services provided in the third node (SRR), and if it 
does not relate to services provided in the third node, to map an address in the 
service invocation request to the number portability database and to relay the 
service invocation request to the second node (SCP), the relayed service in- 
25 vocation request indicating the address range of the address. 

12. A network node (SRR) in a communications system, the net- 
work node comprising at least a number portability service function (SCFJMP) 
having access to a number portability database (NPJDB), the network node 
being arranged to receive service invocation requests, 
30 characterized in that 

in response to receiving a service invocation request, the network 
node (SRR) is arranged to determine whether the service invocation request 
relates to a service function in the network node (SRR), and if the service in- 
vocation request does not relate to a service function in the network node, to 
35 map an address in the service invocation request to the number portability da- 
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tabase and to relay the service invocation request indicating the address range 
of the address. 

13. A network node (SRR) according to claim 12, character- 
ized in that the network node (SRR) is arranged to perform said determina- 

5 tion by comparing the protocol used to relay the service invocation request 
with protocols used by service functions in the network node, and to determine 
that the service invocation request does not relate to a service function in the 
network node, if the protocol is not one of the protocols used by service func- 
tions in the network node. 

10 14. A network node (SRR) according to claim 13, character- 

ized in that if the protocol is one of the protocols used by service functions, 
the network node (SRR) is arranged to further check, whether a service key in 
the service invocation request indicates one of the service functions in the 
network node and to determine that the service invocation request does not 

15 relate to a service function in the network node, if the service key does not in- 
dicate one of the service functions in the network node. 

15. A network node (SRR) according to claim 12, character- 
ized in that the network node (SRR) is arranged to perform said determina- 
tion by checking, whether a service key in the service invocation request indi- 

20 cates one of the service functions in the network node and to determine that 
the service invocation request does not relate to a service function in the net- 
work node, if the service key does not indicate one of the service functions in 
the network node. 

25 
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